REMARKS 



Claims 1-19 are currently active. 
Claims 1, 10 and 19 have been amended. 

Antecedent support for the limitation "that integrates cloud and pipe service into 
a single provisioning model by describing network services in terms of what is experienced by 
an end user's edge devices and by determining a number of transit QOS constraints including 
network devices supporting a service-level agreement and a core network must be 
bi-connected" is found on page 6, lines 3-13 and 18-22. Antecedent support for the limitation 
"said service-level agreement template including a cloud SLA GUI template, cloud SLA 
defaults, a VPN GUI template, and VPN constraints" is found page 6, line 33-page 7, line 1. 

The Examiner has rejected Claims 1-19 as being anticipated by El-Fekih. 
Applicant respectfully traverses this rejection. 

El-Fekih teaches methods, systems, and computer program products for 
managing a service provided by a network. El-Fekih teaches a network 22, a service 
management system 24 and a network management 26 that may be used to interface the service 
management system 24 in the network 22. The network 22 may include one or more core 
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network elements in one or more access network elements. The access network elements 
comprise those network elements that are configured at the edge of the network and provide 
access to the network for access devices from another public or private network. The accessed 
network elements may include one or more ports through which a user network interface or 
network interface may be defined. The service management system 24 may communicate with 
the access network elements and/or the core network elements to collect performance, 
configuration, topology, timing, and/or a traffic data therefrom. The data collected by the 
service management system are stored in repositories for use by other applications. Client 
applications may communicate with the service management system to access reports generated 
by the service management system based on analysis of the collected data and to manage the 
services provided by the network. Capacity planning applications may communicate with the 
service management system to a system administrator in shaping/configuring a topology/shape 
of the network and/or to distribute traffic carried by the network. Billing applications may 
communicate with the service management system to generate bills based on analysis of the 
data collected from the network. The service provisioning applications may communicate with 
the service management system to facilitate the introduction of new services into the network. 

The service management system and/or data processing systems supporting the 
client applications, the capacity planning applications, the billing applications, and the service 
provisioning applications may be configured with computational, storage, and control program 
resident resources for managing service quality. 
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El-Fekih teaches when purchasing ATM service, a customer may be provided 
with a choice of the following various ATM service classes. A service provider may logically 
partition the network into one on more virtual private networks in which a public network 
appears to a customer as a private network. The service management system may be 
embodied as a data processing system. Embodiments of the data processing system may 
include input devices such as a keyboard or keypad or display in a memory that communicates 
with a processor. 

A memory 84 may hold four major categories of software and data: a mediation 
facilities program module, an adaption facilities program module, and access/interface 
facilities program module and a common facilities program module. The mediation facilities 
module may be configured to collect data and other service and network information from the 
network. A service contract manager module may be configured to create, remove and 
maintain information that is associated with a service-level agreement between a service 
provider and a customer of the service provider. The service contract manager module may 
also contain validation rules, crediting rules, and/or business rules to assure the integrity of the 
service-level agreement information that is contained in a local repository. See paragraph 44. 

A service contract manager module may be configured to use service quality 
information obtained from websites, other systems, and/or from a local repository to 
determine whether the service provider provided by a service provider or the traffic generated 



-18- 



by a customer is in conformance with a service-level agreement generated and maintained by 
the service contract module. See paragraph 45. 

The service contract viewer module may be configured to cooperate with the 
service contract manager module to generate an SLA and to request and receive conformance 
reports that indicate whether the SLA is being adhered to. The data may include multiple 
conformance categories that may be based on availability, delay, errors, restore time, and/or 
time between outages. See paragraph 66. 

The service management system may include a service contract manager module 
to may cooperate with a service contract viewer module executing on the client computer 
system to generate and maintain an SLA. In general, an SLA is a contract between a service 
provider and its customers that specifies the various quality parameters and quality levels the 
service provider agrees to provide. Although the SLA is typically based on a service entity, 
the various quality parameters may be VPN-based, VC based, and/or NI based. Embodiments 
may be used to manage an SLA between a service provider and a customer of the service 
provider by first generating an SLA template or package, similar to a service package, and 
then associating the SLA template with a particular customer and service to create an SLA 
contract. See paragraph 102. 
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As is clearly apparent from the above description and teachings of El-Fekih, 



there is no teaching or suggestion of "forming a service-level agreement template that 
integrates cloud and pipe service models into a single provisioning model," as found in the 
amended claims. In fact, El-Fekih is completely silent regarding cloud and pipe service 
models, let alone integrating them into a single provisioning model. To further stress this 
point, the limitation "said service-level agreement template including a cloud SLA GUI 
template, cloud SLA defaults, a VPN GUI template, and VPN constraints" has been 
introduced into the independent claims. El-Fekih does not teach or suggest this limitation 
either. Accordingly, El-Fekih does not anticipate Claims 1-19 of applicant's claimed 
invention, as amended. 

In view of the foregoing amendments and remarks, it is respectfully requested 
that the outstanding rejections and objections to this application be reconsidered and 
withdrawn, and Claims 1-19, now in this application be allowed. 



Respectfully submitted, 
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